Release 10.1A: OpenEdge Development:
Programming Interfaces

Authorizing users from within a given procedure

This sections shows some examples of procedures that you can use to check for user IDs in order to run the given procedure. The following procedure uses _prostar.p:

i-csmnu3.p

DEFINE VARIABLE selection AS INTEGER FORMAT "9". RUN _prostar.p. REPEAT:   FORM  SKIP(2)    "    M A I N M E N U"       SKIP(1)    "  1)  Add a new customer"       SkIP(1)    "  2)  Change customer Information"       SkIP(1)    "  3)  Display orders"       SKIP(1)    "  4)  Create mailing labels"       SKIP(1)    "  5)  Delete a customer"       SKIP(1)    "  6)  EXIT"   WITH CENTERED TITLE "Maintenance and Reporting".   UPDATE SKIP(2) SPACE(1) selection AUTO-RETURN       WITH SIDE LABELS. HIDE.       IF selection EQ 1 THEN RUN i-adcust.p.   ELSE IF selection EQ 2 THEN RUN i-chcust.p.   ELSE IF selection EQ 3 THEN RUN i-itlist.p.   ELSE IF selection EQ 4 THEN RUN i-rept6.p.   ELSE IF selection EQ 5 THEN RUN i-delcus.p.   ELSE IF selection EQ 6 THEN QUIT.   ELSE MESSAGE "Incorrect selection - please try again". END.

This procedure defines user access by first running the _prostar.p procedure before displaying the following main menu in a character environment:

Suppose you want to define, on a per procedure basis, the individuals who can run each of the Maintenance and Reporting menu procedures. You can use the CAN–DO function to check the user ID(s) established by _prostar.p. The i-adcust.p procedure allows you to enter customer information:

i-adcust.p

REPEAT:   INSERT customer WITH 2 COLUMNS. END.

If you want to limit the use of this procedure to database connection that have a database connection ID of manager or salesrep, you can modify the procedure as follows to authorize access based on the database connection ID for single connected database:

i-adcus2.p

The first part of i-adcus2.p authorizes the user to run the procedure. The CAN–DO function compares the values listed in the parentheses against the database connection ID for a single connected database. If the database connection ID does not match any of the values listed, the procedure displays a message and exits. If the database connection ID does match one of the values (listed user IDs), the procedure continues executing.

The ID list you provide in the CAN–DO function is a comma-separated list of user ID tokens. You can use tokens to indicate specific users who have or do not have access. Table 2–10 lists the types of tokens you can specify.

Table 2–10: Values to use for ID lists  

Value	Meaning
*	All users are allowed access.
user	This user has access.
!user	This user does not have access.
string*	Users whose IDs begin with “string” have access.
!string*	Users whose IDs begin with “string” do not have access.

For more information on the CAN–DO function, see the OpenEdge Development: Progress 4GL Reference .

You can also use the USERID function (with a specified or single database connection) to check user IDs in a procedure. Use this function when you want to allow only one user ID access to a procedure:

i-adcus3.p

If the user ID of the user running the procedure is not manager, the procedure displays a message and exits. If the user ID is manager, the procedure continues.

If you use either the CAN–DO function or the USERID function to compare the specified database connection ID with one or more user IDs you hard-code in a procedure, you must modify and recompile that procedure whenever you change the user IDs allowed access to it. You can avoid having to make these changes by building a permissions table for activities in your application. For more information, see the "Defining activities-based user authorization" section.

Also, given a single string of user IDs, the CAN-DO function, by default, validates the single USERID (database connection ID) value for a single database connection. If you connect to more than one database, a USERID function requires a specified logical database name and a CAN–DO function requires a second argument consisting of an explicit USERID function with a specified logical database name. For more information on multiple-database considerations, see OpenEdge Development: Progress 4GL Handbook .

Note: The second argument of the CAN-DO function can also consist of a string expression that specifies an authenticated user ID other than the database connection ID. For example, you can specify the USER-ID attribute of a client-principal object validated against the application trusted domain registry to specify the Progress session ID. In this way, you can use the CAN-DO function to authorize procedure access independent of any database connection. For more information, see the "Authenticating user identities" section. You can also use the list of user roles set for the ROLES attribute on the client-principal object to identify user permissions for the CAN-DO function, for example: IF CAN-DO(hCP:ROLES, "Admin") THEN ...